This method doesn't seem to fit the EntityManager at all: it would honestly be better to not expose it to end-users like this.

I agree that it seems the wrong way to expose it

Hibernate exposes it at EntityManager level because it can be swappable with another implementation.
Default implementation is also reachable from outside, allowing you to provide a ServiceInjector (read as DI Container).
I'm ok to move this to UnitOfWork, but I would not consider this as an extension point (the part I wanted to discuss internally). This means there'll be no interface bound to PersisterFactory.
Right now I made it part of EntityManager and wanted to discuss IF we'd make it an extension point.

TL;DR: the UnitOfWork as-is is already poop: let's stash poop in there instead of shoveling it on other classes.

That makes our EntityManager some kind of locator (meh).
I'd prefer to make a tradeoff here, and do this crappy thing in the UnitOfWork instead (yes, with all the deficiencies that come from it).

The UnitOfWork as we know it will go away at some point in time, while the EntityManager will stay and be consumed by userland.

should it be an interface with a default implementation to make it an extension point ?

Agree: introducing a concrete implementation with no interface seems a bit messy here.

Only if we consider this as an extension point, which in the current state of this PR it isn't.

I agree with guilherme, it is not an extension point at the moment.